d.h. die zu testende Schnittstellen sollen vor der Ausf"uhrung die Konkrete Klassename und alle wichtige Parameter darstellen und nach der Abarbeitung die Ergebnisse ausdrucken bzw. ihre Ende deklarieren,



\section{backup}
\subsection{TDD}
Vor dem Vorkommen von {\bf XP}\cite{Beck00} und {\bf TDD}\cite{Beck03} spielen Modultesten nur eine nachrangige Rolle. Danach ist sich die Situation ver"andert. Als die zentrale Activt"aten innerhalb des XP-Entwicklungszyklus haben Modultesten immer eine gr"o"serer Bedeutung.\\
Die Kern-Konzept von TDD ist \kc{Test-First.}Die weitere Informationen "uber TDD und \kc{Test-First}werden in dem Buch "`Test-Driven Development"' von Kent Beck detailliert erz"ahlt. Bei der Implementierung des NOP-Engine ist dieses Prinzip erf"ullt, d.h. bevor der Implementierung der konkreten Klassen bzw. ihrer Funktionen werden eine Reihe von Testen aufgebaut, und bis einer der Testen ohne Fehler durchlaufen kann, wird die Entwicklung der entsprechenden konkrete Klassen und ihrer Funktionen abgeschlo"sen.
\section{Werkzeuge f"ur Modultesten in JAVA}

\subsection{JUnit}
{\bf JUnit} ist eine quelloffene Rahmenwerk \engl{framework} zur Automatisierung von Modultesten und unter JAVA von Kent Beck und Erich Gamma entwickelt. Einher gehend mit der Ausdehnung der Anwendung von \kc{XP} und \kc{TDD} ist \kc{JUnit} ein Quasi-Standard zum Modultest f"ur JAVA-Programmen geworden. Es wird breit von einer gro"sen Anzahl von JAVA-Projekten akzeptiert.\\
Um die Testf"alle schnell zu entwickeln wird die Version 4.4 von \kc{JUnit} von uns aufgenommen, damit werden die \kc{Annotation} von JAVA und \kc{JMock} unterst"utzt.
\subsubsection{Anwendung von JUnit}
Die Vorgehensweise zum Anwenden von \kc{JUnit 4.4} ist ziemlich einfach,
\begin{itemize}
\item Bezeichnen einer Klasse als eine Test-Klasse mit der Annotaionen \kc{@RunWith,}
\item Deklarieren einer Methode als eine Test-Funktion mit der Annotation \kc{@Test,}
\item Designieren von Methoden als die Vorbedinung bzw. Nachbedingung jeder Test-Funktion mit Hilfe von \kc{@Before} bzw. \kc{@After},
\item Anwenden von \kc{Assertion} zum Vergleichen von den realen Ergebnissen und erwarteten Werten.
\end{itemize}
Die Vorbedingungen von Nachbedingungen sollen f"ur jede Test-Funktion in dieser Test-Klasse ein Mal ausgef"uhrt werden. Eine Test-Klasse in \kc{JUnit} sieht wie den Code von unten aus,
\includeJavaCode{chapters/test/junit_example.java}
Der Parameter von \kc{@RunWith} kann irgendeine \kc{Subobject} von der Klasse \[org.junit.runner.Runner\] sein. In \kc{JMock} und \kc{Spring} stehen ihre eigene "`\kc{Runners}"' f"ur JUnit zur Verf"ugung. Sp"ater zeigen wir an, wie man die "`\kc{Runners}"' von \kc{JMock} und \kc{Spring} verwenden kann. Die Funktion "`\kc{doTest}"' ist eine Test-Funktion, die einen Modul-Test beinh"alt. In der Methode "`\kc{doBefore}"' und "`\kc{doAfter}"' werden die Vorbedingungen und Nachbedingungen f"ur "`\kc{doTest}"' eingestellt.
\subsubsection{Ausf"uhrung einer Test-Klasse}
F"ur das Gugubarra-Projekt wird {\bf eclipse} als die Standard-IDE angewendet. Um eine Test-Klasse von \kc{JUnit} laufen zu lassen muss zuerst die Bibliothek von \kc{JUnit 4.4} als die Projekt-Bibliothek in eclipse manuell\footnote{Die Default-Bibliothek von \kc{JUnit} in eclipse 3.x ist mit der Version {\bf 3.8}} importiert werden, dann kann man durch die Tastenkombination \engl{keybord shortcut} "`\kc{Shift-Alt-X, T}"' oder einen Klick auf "`\kc{Run As $\longrightarrow$ JUnit Test}"' eine Test-Klass von \kc{JUnit} ausf"uhren.
\subsection{JMock}
{\bf JMock} ist eine JAVA-Bibliothek, mit der Mock-Objekten f"ur Modultesten leicht angelegt und angewendet werden k"onnen. Bevor der Anwendung von \kc{JMock}sollen Mock-Objekte erst mal vorgestellt werden. Bei {\bf Mock-Objekten} handelt es sich um eine Test-Technologie, die TDD durch die Simulation der Handlungsweisen von Objekten unterst"utzt. Deise Test-Technologie stammt aus XP\cite{Beck03} und ver"andert die Denkart der Programmierern\cite{Freeman09}. Sie konzentrieren sich nicht nur auf Objekten selbst wie vorher, sonder auch Interaktionen zwischen Objekten. \kc{JMock}ist eines der Werkzeugen zum Anlegen und Verwalten von \kc{Mock-Objekten}.
\subsubsection{Anwendung von JMock}
Anhand der Definition von \kc{Mock-Objekten} muss man zuallererst verstehen, wie \kc{JMock} Objekte und ihre Handlungsweisen simuliert. Angenommen, dass wir eine Klasse "`ToTestClass"' haben und sie besitzt eine Methode \kc{doSomething}, die ein Parameter mit der Typ von Ganzzahl haben und eine Zeichketten zur"ucklierfern sollte. Der folgende Bespiel-Code zeigt die Simulation von "`ToTestClass"' und ihre Methode \kc{doSomething} an,\\
\includeJavaCode{chapters/test/jmock_example.java}
\kc{JMock}bietet ein eigenes "`\kc{Runner}"' mit dem Namen \kc{JMock}. In der Zeile 19 wird eine Fabrik-Objekt mit der Typ "`Mockery"' initialisiert, um Mock-Objekten anzulegen. Durch die Methode \kc{mock} mit dem Paramter, eine Instanz des Klasse-Objekts von "`ToTestClass"', von dieser Fabrik-Objekt wird ein Mock-Objekt von "`ToTestClass"' erstellt. In \kc{JMock} werden Simulationen durch "`Expectations"' realisiert. Von der Zeile 26 bis 30 wurde eine Simulation erzeugt, die die Mothode \kc{doSomething} von "`ToTestClass"' simuliert. Ist die Eingabe von \kc{doSomething} gleich 1, dann soll die Zeichnenketten "`result for test"' zur"uckgeliefert werden. Dabei sind die Eingabe und das Ergebnis der zu simulierenden Methode {\bf final} zu deklarieren.
\subsubsection{Der Nachteil von \kc{JMock}}
Angesichts der Vorgehensweise von \kc{JMock} m"ussen alle simulierte Methoden von Mock-Objekten explizit in der Test-Funktion aufgerufen werden. Es besteht die M"oglichkeit, doppelte Codes zu schreiben, um ein Algorithmus, der eine Methode eines Mock-Objekts aufruft, zu testen. Dieses Problem ist offenbar f"ur alle Bibliotheken von Mock-Objekten. Anhand ihrer Vorteilen ist es tolerabel.\subsection{Das AOP-Packet von Spring}
Um ben"otige Informationen von Modultesten zu formatieren und anzuzeigen, wird die Technologie der {\bf  Aspektorientierte Programmierung} \cite{Aksit04} (engl. \kc{Aspect oriented programming,}kurz. \kc{AOP}) und die Bibliothek "`Log4j"' im Gugubarra-Projekt angewendet. Bei AOP handelt es sich um eine Methode, die anstrebt, verschiedene logische Aspekte eines Anwendungsprogramms voneinander getrennt zu entwerfen, zu entwickeln und zu testen. Die AOP behandelt das Problem der sogenannten \kc{Corss-Cutting Concern,}z.B. Fehlerbehandlung, Loggin, Tracing und Sicherheitsanforderungen. Typischerweise geh"oren sie nicht zur Kernfunktionalit"at der Software, sondern stellen Zusatz- oder Metaanforderungen dar.\\
Das AOP-Packet von dem Spring-Rahmenwerk ist eine Implementierung der dynamischen AOP (gegen AspectJ\footnote{Die Implementierung der AOP in AspectJ ist als {\em statisch} bekannt.}). Es bietet umfangreiche Funktionalit"aten, die die meiste Aufgaben der AOP erf"ullen. Bevor der Anwendung des AOP-Packets werden die folgende Konzepte vorgestellt,
\begin{description}
	\item Pointcut
	\item Advice
\end{description}
 
\subsubsection{3. Berechnen des Parameters $f$}
In der aktuellen Version vom Gugubarra gibt es zwei konkrete Implementierung f"ur die Schnittstelle \kc{IParamFService}. Infolgedessen werden zwei Testf"alle daf"ur aufgebaut.
	\begin{enumerate}
		\item F"ur die Implementierung \kc{DefaultParamFServiceImp}
		\begin{itemize}
			\item Eingabe : 
			\begin{itemize}
				\item Anzahl der Benutzer-Sessionen : 100
				\item Zeitdauer zwischen die neue Benutzer-Session und die Letzte : 1000 Millisekunde
				\item Summe der Zeitdauer aller berechneten Benutzer-Sessionen : 0
			\end{itemize}
			\item Ergebnis : 1.0
		\end{itemize}
		\item F"ur die Implementierung \kc{ParamFServiceImp1}
		
		\begin{itemize}
			\item Eingabe : 
			\begin{itemize}
				\item Anzahl der Benutzer-Sessionen : 99
				\item Zeitdauer zwischen die neue Benutzer-Session und die Letzte : 999 Wochen
				\item Summe der Zeitdauer aller berechneten Benutzer-Sessionen : 0
			\end{itemize}
			\item Ergebnis : 20
		\end{itemize}
	\end{enumerate}
	Wegen der Einfachheit der ersten Implementierung wird sie nur ein mal getestet. In den folgenden Testf"allen ist nur die Zweite weiter anzuwenden.




%--------------------------------------------------------------
\subsection{Beschreiben von Anforderungen}
Ausgehend von ihrer Definition sollten Anforderungen einerseits die Aufgaben von Systemen vermitteln und andererseits die Ziele von Auftraggebern wiederspiegeln. Infolgedessen wird eine Anforderung in dem folgenden Format beschrieben,
\begin{enumerate}
\item Der Benutzer fordert, ...
\item System ist gefordert, ...
\end{enumerate}